Skip to content
This repository was archived by the owner on Feb 25, 2025. It is now read-only.

Remove glitch when displaying platform views #30724

Merged
merged 6 commits into from
Jan 10, 2022

Conversation

blasten
Copy link

@blasten blasten commented Jan 7, 2022

When startRenderingToSurface is called, any current active surface is destroyed.

This is undesired when platform views are displayed because the Engine will continue
to render to this surface once the platform views aren't rendered in the frame.

If the active surface is destroyed, there's a "glitch" caused by the time it takes to create
the new surface.

This issue was introduced after #28894

Fixes flutter/flutter#95343
Fixes flutter/flutter#96177

Emmanuel Garcia added 2 commits January 6, 2022 16:35
@blasten blasten marked this pull request as ready for review January 7, 2022 00:38
@zanderso
Copy link
Member

zanderso commented Jan 7, 2022

The failing unit tests appear to be related.

@blasten
Copy link
Author

blasten commented Jan 8, 2022

The test should be passing now. ptal

Copy link
Contributor

@GaryQian GaryQian left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

// is paused, and rendering continues in a FlutterImageView buffer while the platform view
// is displayed.
//
// startRenderingToSurface may stop rendering to this surface if it believes it already started
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit, the wording here is a bit confusing? Not sure if can be better said.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agreed. Done

@blasten blasten added the waiting for tree to go green This PR is approved and tested, but waiting for the tree to be green to land. label Jan 10, 2022
@fluttergithubbot fluttergithubbot merged commit 8b9f625 into flutter:main Jan 10, 2022
engine-flutter-autoroll added a commit to engine-flutter-autoroll/flutter that referenced this pull request Jan 10, 2022
zanderso pushed a commit to flutter/flutter that referenced this pull request Jan 11, 2022
* 58305d1 Roll Skia from dd575bc0f1f5 to 0056f3f006de (2 revisions) (flutter/engine#30765)

* 92a4f99 Allow additional expose_dirs in flutter_runner (flutter/engine#30749)

* 358605c [web] Remove EngineParagraph and ParagraphGeometricStyle (flutter/engine#30766)

* 8b9f625 Remove glitch when displaying platform views (flutter/engine#30724)

* bd65330 Add missing dependencies to the background image app (flutter/engine#30769)

* 65dfc9e [android] Remove the FlutterView casting, add a @nonnull and fix code style (flutter/engine#30734)

* 00e2a47 Roll Skia from 0056f3f006de to 3e1354a592bc (3 revisions) (flutter/engine#30771)

* 279e3af Implemented library uri support for FlutterFragments and FlutterActivities (flutter/engine#30726)

* 36ad9f1 Roll Skia from 3e1354a592bc to 55b4dc3f7a1c (1 revision) (flutter/engine#30773)
JsouLiang pushed a commit to JsouLiang/engine that referenced this pull request Jan 14, 2022
itsjustkevin pushed a commit to itsjustkevin/engine that referenced this pull request Jan 19, 2022
itsjustkevin added a commit that referenced this pull request Jan 19, 2022
…0918)

* Impl and test (#30488)

* Fix missing shcore.dll error on Windows 7 (#30699)

* Remove glitch when displaying platform views (#30724)

* Win32: Fix Korean text input (#30805)

Fixes an issue with Korean IMEs wherein a text input state update may be
sent to the framework that misleads the framework into assuming that IME
composing has ended.

When inputting Korean text, characters are built up keystroke by
keystroke until the point that either:
* the user presses space/enter to terminate composing and commit the
  character, or;
* the user presses a key such that the character currently being
  composed cannot be modified further, and the IME determines that the
  user has begun composing the next character.

The following is an example sequence of events for the latter case:

1. User presses ㅂ. GCS_COMPSTR event received with ㅂ. Embedder sends
   state update to framework.
2. User presses ㅏ. GCS_COMPSTR event received with 바. Embedder sends
   state update to framework.
3. User presses ㄴ. GCS_COMPSTR event received with 반. Embedder sends
   state update to framework.
4. User presses ㅏ. At this point, the current character being composed
   (반) cannot be modified in a meaningful way, and the IME determines
   that the user is typing 바 followed by 나. GCS_RESULTSTR event
   received with 바, immediately followed by GCS_COMPSTR event with 나.

In step 4, we previously sent two events to the framework, one
immediately after the other:
* GCS_RESULTSTR triggers the text input model to commit the current
  composing region to the string under edit. This causes the composing
  region to collapse to an empty range.
* GCS_COMPSTR triggers the text input model to insert the new composing
  character and set the composing region to that character.

Conceptually, this is an atomic operation. The fourth keystroke causes
the 반 character to be broken into two (바 and ㄴ) and the latter to be
modified to 나. From the user's point of view, as well as from the IME's
point of view, the user has NOT stopped composing, and the composing
region has simply moved on to the next character.

Flutter has no concept of whether the user is composing or not other
that whether a non-empty composing region exists. As such, sending a
state update after the GCS_RESULTSTR event misleads the framework into
believing that composing has ended. This triggers a serious bug:

Text fields with input formatters applied do not perform input
formatting updates while composing is active; instead they wait until
composing has ended to apply any formatting. The previous behaviour
would thus trigger input formatters to be applied each time the user
input caused a new character to be input. This has the add-on negative
effect that once formatting has been applied, it sends an update back to
the embedder so that the native OS text input state can be updated.
However, since the GCS_RESULTSTR event is _immediately_ followed by a
GCS_COMPSTR, the state has changed in the meantime, and the embedder is
left processing an update (the intermediate state sent after the
GCS_RESULTSTR) which is now out of date (i.e. missing the new state from
the GCS_COMPSTR event).

Since GCS_RESULTR events are always immediately followed by a subsequent
GCS_COMPSTR (in the case where composing continues) or a
WM_IME_ENDCOMPOSITION (in the case where composing is finished), and
because the event handlers for both of those send updated state to the
framework, this change eliminates sending the (intermediate) state in
response to GCS_COMPSTR events.

Issue: flutter/flutter#96209 (full fix)
Issue: flutter/flutter#88645 (partial fix)

* Ensure that PlatformViewIOS does not call into Shell semantics APIs during destruction (#30835)

* Ensure that PlatformViewIOS does not call into Shell semantics APIs during destruction (#30835)

Co-authored-by: Tong Mu <[email protected]>
Co-authored-by: Chris Bracken <[email protected]>
Co-authored-by: Emmanuel Garcia <[email protected]>
Co-authored-by: Jason Simmons <[email protected]>
lyuku pushed a commit to lyuku/engine that referenced this pull request Jul 28, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
platform-android waiting for tree to go green This PR is approved and tested, but waiting for the tree to be green to land.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[webview Android] Flicker issue when navigating routes [Android] Severe glitch when navigating to a screen with google_mobile_ads
4 participants